锐捷与思科混合组网场景下 PVST+ BPDU 导致端口阻塞问题
一、网络环境
1. 设备环境
| 设备角色 | 厂商及型号 | 软件版本 | 生成树协议 |
|---|---|---|---|
| 核心交换机 | 锐捷 S7805C | — | MSTP |
| 接入交换机 | Cisco | 12.5 | MSTP |
网络采用锐捷核心、Cisco 接入的混合组网架构，整网统一采用 MSTP，锐捷核心作为整网根桥。
2. 网络拓扑
锐捷 S7805C
MSTP Root
│
┌──────────┴──────────┐
│ │
Cisco SW1 Cisco SW2
MSTP MSTP
二、生成树配置
1. 锐捷核心
锐捷核心启用 MSTP，当前仅配置 MST Instance 0，所有 VLAN 映射至 MST0：
RG_Core#show spanning-tree mst configuration
Multi spanning tree protocol : Enable
Name :
Revision : 0
Instance Vlans Mapped
-------- --------------------------------------------
0 ALL
-----------------------------------------------------
MSTP 状态正常，核心交换机为 MST0 根桥：
RG_Core#show spanning-tree summary
Spanning tree enabled protocol mstp
MST 0 vlans map : ALL
Root ID Priority 0
Address 5000.0003.0001
this bridge is root
Interface Role Sts Cost Prio OperEdge Type
--------------- ---- --- ------- ------- -------- ----------------
Gi0/0 Desg FWD 20000 128 False P2p
Gi0/1 Desg FWD 20000 128 False P2p
核心上联接口配置了 BPDU Filter：
interface GigabitEthernet 0/0
switchport mode trunk
spanning-tree bpdufilter enable
interface GigabitEthernet 0/1
switchport mode trunk
spanning-tree bpdufilter enable
2. Cisco 接入交换机
Cisco SW1、SW2 均启用 MSTP：
ASW1#show spanning-tree summary
Switch is in mst mode (IEEE Standard)
PVST Simulation is enabled
Bridge Assurance is enabled
...
MST0 0 Blocking
0 Listening
0 Learning
8 Forwarding
8 STP Active
MST Region 配置如下：
Name []
Revision 0
Instance Vlans mapped
-------- ---------------------------------------------------------------------
0 1-4094
即 Cisco 接入交换机与锐捷核心均采用 MSTP，且当前均将所有 VLAN 映射至 MST0。
三、故障现象
问题一：网络中持续存在 Cisco PVST+ BPDU
在 Cisco 接入交换机上抓包发现，网络中持续存在目的 MAC 为：
01:00:0C:CC:CC:CD
的 BPDU 报文。
该目的 MAC 为 Cisco PVST+ 所使用的组播 MAC，可作为识别 PVST+ BPDU 的重要特征。
Wireshark 过滤条件：
eth.dst == 01:00:0c:cc:cc:cd
在部分 Cisco 接入交换机上可以持续捕获到 PVST+ BPDU。
同时，故障期间曾出现部分 Cisco 接入交换机上联端口进入 Blocking 状态的现象。
但由于故障发生后现场未能完整保留当时的 STP 状态及 BPDU 报文，目前无法复现该 Blocking 现象，因此暂无法进一步确认端口进入 Blocking 的直接触发原因。
四、BPDU Filter 验证
1. 验证目的
为避免生成树 BPDU 在核心与接入交换机之间传播，在锐捷核心上联接口配置：
spanning-tree bpdufilter enable
按照预期，配置 BPDU Filter 后，该接口不应继续发送或接收生成树 BPDU。
2. 实际验证结果
配置 BPDU Filter 后，在 Cisco 接入交换机上联接口继续进行抓包，并使用：
eth.dst == 01:00:0c:cc:cc:cd
过滤 PVST+ BPDU。
实际仍可以捕获到 PVST+ BPDU。
即：
锐捷核心
│
│ 配置 BPDU Filter
│
↓
Cisco 接入交换机
│
└── 仍可捕获 PVST+ BPDU
因此可以确认：
锐捷核心接口配置 BPDU Filter 后，仍存在目的 MAC 为
01:00:0C:CC:CC:CD的 PVST+ 报文到达 Cisco 上联接口，BPDU Filter 未达到预期的 PVST+ 报文隔离效果。
五、PVST+ 报文特征
经抓包确认，Cisco PVST+ BPDU 使用以下目的 MAC：
| 生成树协议 | BPDU 目的 MAC |
|---|---|
| STP（802.1D） | 01:80:C2:00:00:00 |
| RSTP（802.1w） | 01:80:C2:00:00:00 |
| MSTP（802.1s） | 01:80:C2:00:00:00 |
| Cisco PVST+ | 01:00:0C:CC:CC:CD |
其中：
01:00:0C:CC:CC:CD
是本次问题中用于识别及过滤 Cisco PVST+ BPDU 的关键特征。
六、解决方案
考虑到当前网络已经统一采用 MSTP，且锐捷核心与 Cisco 接入交换机之间无需使用 PVST+ 进行生成树互操作，为避免 PVST+ BPDU 在网络中继续传播，采用二层 MAC ACL 对 PVST+ BPDU 进行过滤。
配置如下：
mac access-list extended NoPVST
10 deny any host 0100.0ccc.cccd etype-any
20 permit any any etype-any
interface Vlan 1
mac access-group NoPVST in
mac access-group NoPVST out
其中：
0100.0ccc.cccd
对应：
01:00:0C:CC:CC:CD
即 Cisco PVST+ BPDU 使用的目的 MAC。
ACL 处理逻辑：
目的 MAC = 01:00:0C:CC:CC:CD
│
└── DENY → 丢弃 PVST+ BPDU
其他二层报文
│
└── PERMIT → 正常转发
七、验证结果
配置 MAC ACL 后，再次在 Cisco 接入交换机上联接口进行抓包，并使用：
eth.dst == 01:00:0c:cc:cc:cd
进行过滤。
验证结果显示：
网络中不再能够捕获到目的 MAC 为
01:00:0C:CC:CC:CD的 PVST+ BPDU 报文。
PVST+ BPDU 已被有效隔离，网络运行恢复正常，问题得到解决。
结论
通过现场抓包确认，网络中存在 Cisco PVST+ BPDU，其目的 MAC 为：
01:00:0C:CC:CC:CD
在锐捷核心接口配置 BPDU Filter 后，仍能够在 Cisco 接入交换机上联接口捕获到 PVST+ BPDU，说明当前 BPDU Filter 配置未能有效阻断该类 PVST+ 报文。
由于故障发生时未能保留 Cisco 端口 Blocking 状态对应的完整 STP 日志及 BPDU 报文，目前无法确认 PVST+ BPDU 与端口 Blocking 之间的直接触发关系。因此，建议后续如再次发生端口 Blocking，应第一时间在 Cisco 侧执行：
show spanning-tree inconsistentports
show spanning-tree interface <interface> detail
show spanning-tree vlan <vlan>
show spanning-tree mst detail
并同步抓取故障接口 BPDU，以进一步确认具体的 Blocking 触发机制。
最终通过在二层转发路径上针对：
01:00:0C:CC:CC:CD
实施 MAC ACL，成功阻断 Cisco PVST+ BPDU，验证网络中不再出现 PVST+ 报文，问题得到解决。